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FOREWORD 

Among  the  responsibilities  assigned  to  the  Office  of  the  Manager,  National 
Communications  System,  is  the  management  of  the  Federal  Telecommunication 
Standards  Program.  Under  this  program,  the  NCS,  with  the  assistance  of  the 
Federal  Telecommunication  Standards  Committee  identifies,  develops,  and 
coordinates  proposed  Federal  Standards  which  either  contribute  to  the 
interoperability  of  functionally  similar  Federal  telecommunication  systems  or 
telecommunication  systems.  In  developing  and  coordinating  these  standards,  a 
considerable  amount  of  effort  is  expended  in  initiating  and  pursuing  joint 
standards  development  efforts  with  appropriate  technical  committees  of  the 
International  Organization  for  Standardization,  and  the  International  Telegraph 
and  Telephone  Consultative  Committee  of  the  International  Telecommunication 
Union.  This  Technical  Information  Bulletin  presents  an  overview  of  an  effort 
which  is  contributing  to  the  development  of  compatible  Federal,  national,  and 
international  standards  in  the  area  of  Facsimile.  It  has  been  prepared  to 
inform  interested  Federal  activities  of  the  progress  of  these  efforts.  Any 
comments,  inputs  or  statements  of  requirements  which  could  assist  in  the 
advancement  of  this  work  are  welcome  and  should  be  addressed  to: 

Office  of  the  Manager 
National  Communications  System 
ATTN:  NCS-TS 

Washington,  DC  20305-2010 
(202)  692-2124 
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1.0  INTRODUCTION 


This  document  summarizes  work  performed  by  Delta  Information  Systems,  Inc.,  (DIS)  for 
th  Office  of  Technology  and  Standards  of  the  National  Communications  System,  an 
organization  of  the  U.S.  Government,  headed  by  acting  National  Communications  System  . 
Assistant  Manager  Dennis  Bodson.  Mr.  Bodson  is  responsible  for  the  management  of  the 
Federal  Telecommunications  Standards  Program,  which  develops  telecommunications 
standards,  the  use  of  which  is  mandatory  for  all  Federal  agencies.  The  purpose  of  this 
effort,  performed  under  task  order  number  87-C-0078-002  of  contact  number  DCA100-87- 
C-0078,  was  the  development  of  the  software  necessary  to  support  the  establishment  of  a 
Raster  Testing  System  which  will  test  for  conformance  to  CCITT  Recommendation  T.6. 
Recommendation  T.6  defines  the  compression  algorithm  for  Group  4  Facsimile.  T.6 
Compression  Testing  is  part  of  the  general  Group  4  Validation  System  which  when  complete 
will  test  the  upper  layer  protocols  of  Group  4  Facsimile. 


2.0  FUNCTIONAL  DESCRIPTION 

2.1  Overview 

In  order  to  verify  that  a  User  facility  is  conforming  to  CCITT  Recommendation  T.6  for 
Group  4  Raster  Image  compression  and  decompression,  a  conformance  verification  procedure 
was  developed.  This  procedure  consists  of  the  generation  of  a  Raster  Image  tape  containing 
"Standard  Images"  to  be  processed  by  a  User  requesting  verification.  The  output  images  from 
the  User  process  will  then  be  compared  aqainst  known  "Good"  images  to  verify  that  the 
compression  and  decompression  algorithms  implemented  by  the  User  were  in  accordance  with 
CCITT  Recommendation  T.6.  If  errors  were  found  in  comparing  the  Users’  output  images  and 
the  known  good  images,  an  error  log/listing  would  be  generated  identifying  where  the  errors 
occurred  (See  Figure  2-1). 

In  order  to  support  this  verification  procedure  a  Group  4  Conformance  System  was 
developed.  The  conformance  system  consists  of  three  parts: 

-  Generation  of  a  Standard  Raster  Image  Tape  to  be 
processed  by  the  user. 

-  Validation  of  the  User's  raster  image  tape  containing 
the  output  images. 

-  Verification  of  the  User's  compression/decompression 
algorithm. 

2.1.1  Raster  Image  Tape  Generation 

The  generation  of  the  Standard  Raster  Image  Tape  consists  of  writing  raster  image  files 
to  magnetic  tape  in  the  format  specified  by  MIL-STD-1840A  and  MIL-R-28002.  This  format 
will  be  discussed  in  detail  later.  Specifically,  the  raster  image  tape  contains  two  sets  of  test 
image  files.  The  first  set  of  image  files  contains  uncompressed  bit-map  images  to  be 
compressed  by  the  User.  The  second  set  of  image  files  contains  test  images  compressed  using 
the  CCITT  Group  4  algorithm  to  be  decompressed  by  the  User.  The  two  test  sets  include 
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FROM  USER  FACILITY 


FIGURE  2-1  -  CONFORMANCE  TESTING  SYSTEM 


binary  images  that  test  not. only  the  User's  ability  to  process  different  encoding  situations 
but  also  the  ability  to  handle  the  different  document  sizes. 

2.1.2  Raster  Image  Tape  Validation 

The  validation  of  the  User's  raster  image  tape  insures  that  it  was  written  in  accordance 
with  MIL-STD-1840A  and  MIL-R-28002  and  that  the  required  number  of  image  files  (both 
compressed  and  decompressed)  are  present  on  the  tape.  The  validation  process  lists  in  a  log 
file  any  discrepancies  between  the  standards  and  the  actual  tape  format.  The  image  files  are 
also  extracted  from  the  tape  for  further  processing. 

2.1.3  Verification  of  Group  4  Compression/Decompression 

The  verification  of  the  User's  compression/decompression  algorithm  is  accomplished  by 
doing  a  bit-by-bit  comparison  of  the  Users'  output  files  with  their  corresponding  "Good" 
images  within  the  Group  4  Conformance  System.  This  comparison  is  a  two  part  procedure 
comparing  the  bit  mapped  (uncompressed)  images  and  then  the  Group  4  encoded  (compressed) 
image  files.  Any  discrepancies  will  be  noted  and  logged  in  a  Conformance  Test  Report. 

Although  the  Conformance  System  was  developed  specically  for  the  verification  of  Group 
4  Image  Compression  and  Decompression,  the  software  procedures  which  generate  and 
validate  the  tape  format  are  not  specific  to  Group  4  Raster  Image  Tapes.  They  are  capable  of 
processing  any  ANSI  standard  labelled  tapes.  In  addition  the  image  file  extraction  procedure 
is  not  specific  to  raster  image  files,  but  can  extract  any  of  the  file  types  specified  in  MIL- 
STD-1840A  (e.g.  Page  Description  Language  and  SGML  Conforming  File  Sets  etc.). 


2.2  Tape  File  Layouts 
2.2.1  General  Description 

The  Standard  Raster  Image  Tape  Format  is  defined  in  MIL-STD-1840A  and  MIL-R-28002 
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as  mentioned  previously.  These  standards  require  that  the  magnetic  tape  be  labelled  in 
accordance  with  FIBS  PUB  79  and  also  that  document  declaration  files  be  present  describing 
the  document  images  on  the  tape.  Figure  2-2  shows  an  example  of  a  raster  image  tape 
format.  The  Volume  Header  Label  (VOL1)  identifies  the  tape  and  is  followed  by  Header  Labels 
(HDR1  &  HDR2),  data,  and  Trailer  Labels  (EOF1  &  EOF2)  groups  for  each  data  file  recorded  on 
the  tape.  In  addition,  at  least  the  first  data  file  must  be  a  document  declaration  file 
defining  the  raster  images  that  follow.  If  multiple  documents  are  present  on  the  tape  there 
must  be  a  document  declaration  file  for  each.  These  declaration  files  are  grouped  at  the 
beginning  of  the  tape.  The  raster  image  file  groups  must  follow  the  declaration  files  in  the 
same  order  as  the  declaration  files. 

2.2.2  Contents 

The  Volume  Tape  Label(s)  contains  the  Volume  Identification,  accessibilty  and  Owner 
Identification  and  is  the  first  record  recorded  on  the  tape.  The  Volume  Label(s)  is  followed 
by  data  files  which  are  delimited  by  Header  and  Trailer  Labels  and  Tape  End  of  File 
Marks(TM).  The  first  Header  label  contains  the  file  identifier  (file  name),  any  file  set 
information  for  the  data,  generation  data,  block  length  and  record  length  information.  The 
trailer  labels  mirror  the  header  labels,  but  also  contain  the  tape  block  count  for  the  data 
file.  The  volume  labels,  header  labels  and  trailer  labels  are  fully  defined  in  FIPS  PUB  79  and 
ANSI  Standard  X3.27. 

As  mentioned,  the  first  data  file  on  the  tape  is  a  document  declaration  file  describing 
the  raster  image  files  for  the  first  document.  The  declaration  file  is 
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EOF  1  EOF  2  TM 


HDR2  TM 


SECOND  DOCUMENT  DECLARATION  FILE: 


EOF  1  EOF  2  TM  HDR1  HDR2 


FIRST  IMAGE  FILE: 

D001R001 

TM 

1 

EOF  1  EOF  2  TM  HDR1  HDR2  TM 


SECOND  IMAGE  FILE:  D001R002 


EOF1  EOF 2  TM  HDR1  HDR2 


THIRD  IMAGE  FILE:  D002R001 


EOF1 

EOF2 

TM 

TM 

Figure  2-2  -  Raster  Image  Tape  Format 
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comprised  of  fifteen(15)  records.  These  records  contain  source  and  destination 
identification,  revision  level,  dates,  file  count  and  security  information  for  the  document 
(Figure  2-3).  If  more  than  one  document  is  recorded  on  the  tape,  the  document  declaration 
files  for  all  documents  are  recorded  prior  to  the  raster  image  files  for  the  first  document. 

The  raster  image  file  structure  is  defined  in  MIL-STD-1840A  and  MIL-R-28002.  They 
specify  that  the  image  file  is  comprised  of  two  parts  (Figure  2-4).  The  first  part  contains 
the  raster  file  header  records  that  characterize  the  image  encoded  by  the  raster  data.  All 
the  file  header  records  are  in  the  first  block  of  the  file.  The  second  part  of  the  file  contains 
the  raster  binary  data  encoded  using  CCITT  Recommendation  T.6.  The  binary  data  occupies 
data  block  2  through  the  last  block  of  the  file.  Since  the  standards  only  identify  two  raster 
file  types,  Type  1  -Group  4  encoded  and  Type  2  -  Open  Document  Architecture  encoded,  a 
third  raster  type  for  uncompressed  raster  binary  data  is  required  for  the  Standard  Image 
Tape  used  in  the  Conformance  System.  This  third  type  is  Type  9  and  is  indicated  in  record  7 
of  the  file  header  records. 

2.3  Procedure/Use 
2.3.1  Introduction 

The  Group  4  Conformance  System  performs  3  primary  functions:  tape  generation,  tape 
validation,  and  image  verification  (Figure  2-5).  These  functions  are  assisted  by  a  group  of 
supplemental  procedures  that  aid  in  the  creation  and  handling  of  the  Standard  Raster  Image 
Tape.  The  tape  generation  function  is  supported  by  the  procedures  necessary  to 
create/modify  ANSI  standard  labels,  create/modify  a  document  declaration  file,  and  creation 
of  the  raster  Image  file  with  its  associated  header  records.  The  tape  validation  function  is 
supported  by  those  procedures  required  to  validate  the  labels,  the  declaration  file  and  the 
corresponding  tape  contents,  and  also  the  extraction  of  the  raster  image  files  from  the  tape 
for  compression/decompression  verification.  The  image  verification  is  supported  by  the 
procedures  that  compare  compressed  and  decompressed  binary  bit  images  and  identify 
encoding  and  decoding  errors. 
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Record  1  -  Source  System 

-  Character  String  containing  Name  and  Address  of 
System  of  Origin. 

Record  2  -  Source  System  Document  Identification 

-  Character  String  used  by  the  source  system  to 
uniquely  identify  a  document. 

Record  3  -  Source  System  Related  Document  Identification 

-  Character  String  used  by  the  source  system  to  relate 
this  document  to  another  document. 

Record  4  -  Highest  Revision  and  Change  Level 

-  Character  String  indicating  revision  and  change  level. 

Record  5  -  Date  of  Issue 

-  Date  of  Issue  or  Last  change  to  the  document  - 
YYYYMMDD. 

Record  6  -  Destination  System 

-  Character  String  containing  Name  and  Address  of 
Destination  System. 

Record  7  -  Destination  System  Document  Identifier 

-  Character  String  used  by  the  destination  system  to 
uniquely  Identify  a  document. 

Record  8  -  Destination  System  Related  Document  Identification 

-  Character  String  used  by  the  destination  system  to 
relate  this  document  to  another  document. 

Record  9  -  Date  Of  Transfer 

-  Date  the  Document  was  transferred  to  transmission  media. 

Record  10  -  Delivery  Accounting 

-  Freeform  record  containing  delivery  information. 

Record  11  -  File  Count 

-  Character  String  Containing  number  of  files  and  file 
type  e.g.  R14  -  14  Raster  Image  Files. 

Record  12  -  Title  Security  Label 

-  Character  string  identifying  security/sensitivity 
level  on  the  document  title. 

Record  13  -  Document  Security  Label 

-  Character  string  identifying  security/sensitivity 
level  on  any  file  within  the  document. 

Record  13  -  Document  Type 

-  Character  String  used  by  source  system  to  uniquely 
identify  a  document  type. 

Record  14  -  Document  Title 

-  Character  String  identifying  the  document. 


Figure  2-3  -  Declaration  File  Record  Contents 


Raster  Image  File  Tape  Blocks 

1st  Block  2nd  Block  3rd  Block  Block  "n" 


FILE 

RASTER 
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BINARY 

RECORDS 
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— 
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Raster  Data  Type 
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Raster  Image  Orientation 
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Raster  Image  Density 
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— 

Notes 

Figure  2-4  -  Raster  Image  File  Structure 

2  - 


8 


CONFORMANCE 

TESTING 

SOFTWARE 


2 


9 


FIGURE  2-5  -  FUNCTIONS  OF  GROUP  4  CONFORMANCE  SYSTEM 


2.2.2  Image  Tape  Generation 

/ 

The  Image  Tape  generation  function  will  write  to  magnetic  tape  a  set  of  raster 
image  files  as  specified  by  the  user.  Before  the  tape  generation  is  actually  begun,  the 
system  will  check  for  the  existence  of  the  required  tape  labels,  declaration  files(s)  and 
raster  image  files  with  headers.  If  any  of  these  items  are  not  present,  the  operator  will  be 
informed  of  the  missing  item  and  requested  to  create  the  missing  item  using  the  appropriate 
system  utility.  Once  all  the  items  are  available,  the  tape  write  procedure  will  be  initiated. 

In  the  event  of  a  tape  failure,  the  operator  will  be  alerted  and  prompted  for  remedial  action. 
Upon  completion  of  the  tape  generation,  a  log  of  the  tape  contents  will  be  displayed. 

2.2.3  Image  Tape  Validation 

The  Image  Tape  validation  function  checks  both  the  tape  format  and  tape 
contents.  The  validation  function  first  reads  and  logs  to  the  system  log  file  the  tape  labels 
while  insuring  compatibility  with  the  appropriate  standards.  Each  declaration  file  is  then 
read  and  the  contents  of  each  record  are  written  to  the  system  log  file.  Upon  the  completion 
of  the  processing  of  the  declaration  file(s),  the  raster  image  files  are  processed.  Each  image 
file  is  read  with  the  header  records  being  extracted  and  written  to  the  system  log  file  for 
review.  If  the  tape  is  successfully  validated,  then  the  individual  raster  image  files  are 
transferred  to  disk  files.  Each  of  the  disk  image  files  is  then  split  into  two  files.  The  first 
file  contains  the  raster  image  file  header  records  and  the  second  file  contains  the  raster 
binary  data.  The  raster  binary  data  file  and  Its  associated  raster  header  file  are  now  ready 
for  Group  4  verification. 

2.2.4  Image  Verification 

Upon  completion  of  the  Image  Tape  Validation  function  the  binary  data  from  each 
image  file  on  the  input  tape  is  available  for  Group  4  T.6  verification.  The  image  file  header 
file  associated  with  each  image  binary  data  file  contains  the  information  needed  to  properly 
process  the  image.  The  image  type  information  in  record  7  of  the  header  records  determine 
whether  the  image  is  compressed  or  uneompresssed.  If  the  image  is  a  type  1,  it  is  a 
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compressed  image  and  will  be  compared  against  the  Conformance  Systems  corresponding 
"Good"  compressed  image.  If  the  image  is  a  type  9,  it  is  an  uncompressed  (bit  mapped)  image 
and  will  be  compared  against  the  systems  corresponding  "Good"  uncompressed  image.  This 
image,  since  it  is  bit  mapped,  can  also  be  plotted  if  required.  Independent  of  the  image  type, 
any  comparison  errors  will  be  displayed  and  logged  to  the  system  log  file.  This  process  is 
done  for  each  image  on  the  input  tape.  If  during  this  process  it  is  found  that  images  are 
missing  (either  compressed  or  uncompressed)  from  the  image  tape,  the  image  file  names  will 
be  logged  for  evaluation. 
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3.0  CONCLUSIONS  AND  RECOMMENDATIONS 

Upon  completion  of  the  Group  4  Conformance  System,  some  preliminary  raster  image  tapes 
were  processed.  During  this  processing  some  inconsistencies  were  found  that  need 
clarification. 

-  Although  the  ANSI  3.27  specification  defines  the  block  pad  character  as  a  "  ~  " 
(hex  3e)  some  tapes  used  a  "space"  character.  The  use  of  the  proper  character  should  be 
noted  in  MIL-STD-1840A  because  of  the  use  of  padded  blocks  in  declaration  files  and  raster 
data  files. 

-  ANSI  3.27  allows  variable  length  blocks  within  a  file  on  magnetic  tape.  Because 
of  this,  record  length  errors  cannot  be  detected  when  reading  the  image  file  from  tape.  If  a 
record  length  does  occur,  the  image  file  comparision  fails  and  a  compression  or 
decompression  error  is  logged  erroneously.  To  avoid  this  problem  the  raster  image  tape 
should  be  a  fixed  block  size. 

-  MIL-STD-1840A  specifies  that  the  raster  data  file  header  records  are  128  bytes 
in  length.  One  tape  that  was  processed,  specified  in  Header  Label  2  (HDR2)  a  record  length  of 
512.  Since  this  record  length  referred  to  the  raster  image  data  record  it  was  correct  but 
inconsistent  with  the  header  record  block.  It  should  be  noted  in  MIL-STD-1840A  that  the 
HDR2  record  length  field  should  be  128  since  record  size  in  a  bit  image  file  is  meaningless. 

This  implementation  of  the  Conformance  System  only  addresses  the  verification  of  Group 
4  Image  compression  and  decompression  in  accordance  with  CCITT  Recommendation  T.6.  As 
was  noted  previously,  the  software  that  was  developed  is  not  specific  to  Group  4  Images  and 
could  be  extended  to  include  Raster  Type  II  files  encoded  using  the  Open  Document 
Architecture  and  Interchange  Format.  Although  not  currently  included  within  MIL-R-28002, 
compression  and  decompression  of  gray  scale  images  could  also  be  verified  by  the 
conformance  system. 

Another  possible  extension  to  the  Conformance  System  is  to  allow  the  use  of  floppy  disk 
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media  along  with  magnetic  tape  as  a  method  of  transmission.  With  the  introduction  of  the 
large  capacity  3.5"  floppy  disks  (approx.  20  meg),  all  but  the  largest  uncompressed  images 
can  be  stored  on  a  single  floppy. 
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4.0  SOFTWARE  SPECIFICATIONS 
4.1  Introduction 

According  to  government  specifications  MIL-STD-1840A  and  MIL-R-28002,  raster 
images  are  to  be  stored  on  magnetic  tape  in  a  specialized  format  which  includes  information 
on  the  raster  image  itself,  and  the  document  of  which  the  raster  image  is  a  part,  as  well  as 
the  actual  compressed  image  information.  The  files  are  to  be  stored  on  9-track  magnetic 
tape  written  in  accordance  with  ANSI  standard  X3.27-1987.  The  Group  4  Conformance 
System  permits  the  user  to  generate  a  tape  in  this  format  consisting  of  the  image  data  files 
required.  After  processing  the  image  data  files,  the  User  requesting  Group  4  verification 
returns  the  output  files  of  their  system  in  the  same  tape  format.  The  Conformance  System 
validates  the  image  tape  and  then  transfers  the  raster  files  from  ANSI  tape  format  to  a 
local  disk  drive.  Once  the  files  are  transferred  the  non- image  information  is  stripped  from 
the  file  leaving  only  the  binary  image  data  for  processing.  The  Users'  binary  images  are 
then  compared  against  the  corresponding  Conformance  System  "Good"  image  files  to  insure 
Group  4  compatibility. 

.  4.1.1  System  Functions/Procedures 

The  Conformance  system  processing  of  the  raster  images  is  broken  down  into  several 
procedures,  each  of  which  is  handled  by  a  single  program.  In  addition,  there  are  several 
utility  programs  which  aid  in  the  generation  of  the  raster  file  format  information,  and  in 
the  transfer  of  files  from  disk  to  the  tape. 

The  first  procedure  is  the  transfer  of  the  raster  image  data  files  to  magnetic  tape.  This 
is  accomplished  with  the  "IMG_XFER_D2T"  program.  IMG_XFER_J)2T  is  an  interactive 
program,  which  allows  the  user  to  select  which  files  to  transfer  to  tape.  In  addition  to  the 
raster  image  data  files,  IMG_XFER_D2T  also  requires  the  presence  of  header  and  trailer 
label  files,  and  declaration  files  to  ^te. 

There  are  several  utility  programs  which  aid  in  the  creation  and  maintenance  for  the 
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files  required.  The  program  "CREAT_DCLR_FL"  aids  the  user  in  the  creation  arid  editing  of 
document  declaration  files,  which  must  accompany  any  document  on  tape.  The  program 
”CREAT_IMG_HDR''  helps  the  generation  and  modification  of  raster  file  header  records,  and 
the  program  "CREAT_LBL_HDR"  scans  through  a  disk  file  and  generates  the  appropriate  HDR 
and  EOF  files  for  the  user. 

In  addition,  the  assembly  of  a  raster  image  file  from  raster  binary  data  and  header 
records  may  be  required.  This  is  accomplished  by  the  "IMG_FILE_GEN"  program. 
IMG_FILE_GEN  combines  the  information  from  two  files  with  the  '.HDR'  and  ’.DAT';  the 
'.HDR'  file  contains  the  11  header  labels,  and  the  '.DAT'  file  contains  the  raster  image 
information.  IMG_FILE_GEN  concatenates  the  two  files,  padding  the  .DAT  file  to  a  length  of 
one  tape  block,  as  per  MIL-STD-1840A  specs.  All  of  these  programs  are  interactive  and  are 
documented  in  later  sections  of  this  document. 

The  second  procedure  is  the  validation  and  listing  of  the  label  and  image  file 
information  present  on  the  ANSI  tape.  This  process  is  performed  by  a  "IMG_TAPE_VAL" 
program.  This  program  verifies  the  tape  format  and  writes  the  label  Information  to  a  System 
Log  file  along  with  the  file  information  present  in  the  Document  Declaration  Files  and  their 
associated  Raster  Image  files.  Any  discrepancies  between  the  tape  being  processed  and  the 
government  specifications  will  be  noted.  If  the  tape  format  is  such  that  the  tape  cannot  be 
fully  processed,  the  process  will  be  aborted. 

Procedure  3  is  the  transfer  of  any  raster  file  from  ANSI  tape  format  to  a  local  disk. 

This  is  accomplished  with  the  "IMG_XFER_T2D"  program.  IMG_XFER__T2D  is  capable  of 
processing  fixed  and  variable  length  records,  with  block  sizes  up  to  8192  bytes;  fixed 
length  tape  files  are  written  as  direct  access  files  on  disk,  and  variable  length  tape  files 
are  written  as  sequential  access  files  on  disk.  IMG_XFER_T2D  may  be  run  in  an  interactive 
mode,  where  the  program  moves  through  the  tape  files  sequentially  and  queries  the  user 
whether  to  transfer  each  file,  or  in  an  automatic  mode,  where  the  program  simply  transfers 
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every  file  it  encounters  to  disk.  IMG_XFER_T2D  generates  data  files  in  addition  to  the 
'actual'  tape  files,  which  contain  information  from  the  tape  files'  header  and  trailer  label 
blocks.  Each  disk  file  generated  has  its  name  prefaced  with  an  operator  assigned  three 
character  Source  identifier.  This  is  required  since  image  files  names  will  be  identical  from 
various  user  tapes. 

Procedure  4  involves  separating  the  raster  image  header  records  from  the  raster  image 
binary  data  in  the  image  file.  This  is  accomplished  by  the  "IMG_FILE_SPLT"  program.  The 
image  file  is  split  into  two  segments;  the  first  segment,  with  an  '.HDR'  extender,  contains 
the  first  11  records  of  the  file  (i.e.  the  header  records),  and  the  second  segment,  with  a 
'.DAT'  extender,  contains  the  actual  raster  binary  image  information.  At  this  point,  the 
raster  image  may  be  processed. 

The  fifth  and  final  procedure  is  the  comparison  of  the  image  binary  data  files.  The 
program  "IMG_FILE_CMP"  performs  this  function.  Using  the  information  present  in  the 
raster  image  header  file,  the  Conformance  System  compares  the  User  processed  image  file 
against  the  corresponding  Conformance  System  "Good"  image  file.  This  comparision  is  done 
on  a  bit-by-bit  basis  identifying  any  descrepancies.  If  the  errors  found  in  the  User 
processed  file  render  the  remainder  of  the  comparision  impossible,  the  process  will  abort. 

All  errors  found  will  be  logged  to  the  system  error  log  file. 

4.2  Software  Program  Description 

4.2.1  Image  Transfer  Disk  to  Tape  -  IMG__XFR_D2T 

4. 2. 1.1  Introduction. 

IMG_XFR_D2T  is  a  program  designed  to  use  a  series  of  disk  files  to  assemble  an  ANSI- 
standard  Level  III  labeled-format  magnetic  tape.  It  can  process  direct  and  sequential 
access  record  files,  and  can  write  block  lengths  on  the  tape  of  up  to  8192  bytes;  segmented 
records  and  multi-volume  file  sets  are  not  supported  at  this  time,  nor  are  block  offsets 
used  when  writing  files.  IMG_XFR_D2T  is  run  interactively,  and  will  transfer  a  single  file 
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or  collection  of  files  to  magnetic  tape. 

4.2. 1.2  IMG_XFR_D2T  Data  Inputs 

4.2. 1.2.1  Disk  File  Inputs  -  Storage  and  Naming  Conventions 

IMG_XFR_D2T  uses  several  disk  files  to  assemble  a  single  file  on  magtape.  Specifically, 
IMG_XFR_D2T  uses  special  on-disk  label  files  to  specify  which  files  are  to  be  transferred 
to  magnetic  tape,  and  the  manner  in  which  to  store  those  files.  These  label  files  are  given 
a  three  character  source  identification  (sid),  a  two  or  three  letter  content  code,  followed 
by  a  three-digit  number  which  is  used  to  indicate  the  file  group  to  which  a  label  file 
belongs.  The  following  list  specifies  the  letter  codes  of  the  label  files,  and  what 
information  is  stored  in  that  type  of  label  file. 

sidHDR  denotes  a  file  containing  header  label  information 
sidEOF  denotes  a  file  containing  end-of-file  label 
information 

sidEOV  denotes  a  file  containing  end-of-file-section  label 
information  from  the  tape  end-of-file-section 

Every  IMG_XFR__D2T  label  file  must  be  in  sequential-access  disk  format.  The  disk  files 
containing  the  actual  image  records  to  be  transferred  may  be  either  direct-access  or 
sequential-access.  The  name  of  the  disk  file  containing  the  records  to  be  transferred  is 
stored  in  the  HDR  data  file. 

4. 2. 1.2. 2  Disk  File  Inputs  -  Contents  and  Organization 

-  Header  and  Trailer  Data  Files  (HDR,  EOF,  EOV  Flies) 

Header  and  EOF/EOV  (or  "trailer")  data  file  records  are  organized  in  the  same  manner 
for  IMG_XFR_D2T's  use;  therefore  a  common  treatment  shall  be  given. 
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Each  header  or  trailer  data  file  consists  of  at  least  two  sequentially-organized 
records,  80  characters  in  length.  The  first  record  contains,  verbatim,  the  information  to  be 
stored  in  the  HDR1,  EOF1  or  EOV1  label  on  tape.  The  second  record  contains,  also  verbatim, 
the  information  to  be  stored  in  the  HDR2,  EOF2  or  EOV2  label  on  tape.  Any  additional 
records  contained  in  a  header  or  trailer  data  file  are  ignored  by  IMG_XFR_D2T.  It  should  be 
noted  at  this  point  that,  duiing  operation,  IMG_XFR_D2T  searches  first  for  an  EOFxxx  file, 
and  then  for  an  EOVxxx  file.  If  both  an  EOF  and  an  EOV  file  are  present,  IMG_XFR_D2T 
will  always  use  the  EOF  file.  Therefore,  if  the  user  is  transferring  several  files  to  tape,  it 
would  probably  be  a  good  idea  to  purge  all  EO?xxx  files  from  the  disk  before  creating  new 
trailer  data  files.  This  will  ensure  that  IMG_XFR_D2T  will  not  use  an  old  EOF  file  in  place 
of  a  new  EOV  file. 

-  "Data  of  Interest"  Files  (DAT  Files) 

DAT  files  contain  the  actual  records  to  be  placed  upon  the  tape,  and  may  consist  of 
either  direct  access  records  (i.e.  fixed  length),  or  sequential  access  (i.e.  variable  length) 
records.  IMG_XFR_D2T  determines  the  type  of  file,  and  writes  to  tape  a  file  using  fixed 
length  records  if  the  DAT  file  is  direct  access,  and  variable  length  records  if  the  DAT  file 
is  sequential  access. 

IMG_XFR_D2T  can  process  fixed  or  variable  length  records  of  up  to  2048  characters 
long;  records  longer  than  this  will  be  truncated. 

4.2. 1.3  Operator  Inputs 

IMG_XFR_D2T  is  an  interactive  program,  and  will  request  several  pieces  of  information 
from  the  operator.  During  the  course  of  operation,  IMG_XFR__D2T  will  need  to  know  the 
range  of  files  to  transfer  (these  numbers  correspond  to  the  range  of  number  codes  used 
with  the  label  files)  and  the  name  of  the  file  set  being  transferred. 
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4.2. 1.4  Operation 

Upon  initiation  IMG_XFR_D2T  will  prompt  the  operator  for  the  starting  and  ending 
numbers  to  transfer;  the  operator  enters  the  starting  and  ending  numbers  of  the  file 
groups  t<>  be  transferred.  If  the  operator  wishes  to  only  transfer  one  file,  then  these 
numbers  should  be  the  same.  For  example,  entering  T  as  the  starting  number  and  *5'  as  the 
ending  number  would  transfer  file  groups  1  through  5  to  tape. 

TMG_XFR_D2T  will  also  request  that  the  operator  input  a  name  for  the  file  set  to  which 
the  files  belong.  The  default  value  for  this  is  'DIS_0l'.  Operator  entries  should  be  6 
characters  or  less,  and  should  consist  entirely  of  a-eharacters. 

If  IMG_XFR_D2T  detects  the  presence  of  a  file  named  'VOL. 000'  it  will  query  the 
operator  whether  to  transfer  this  to  tape  as  a  volume  header  label.  If  the  operator  wishes 
to  perform  this  transfer,  the  tape  is  rewound  and  the  label  is  written  to  tape.  If  the 
operator  specifies  not  to  transfer  the  existing  Volume  header,  a  new  one  will  be  created 
and  written  for  the  current  data  set. 

At  this  point,  operation  proceeds  fully  automatically.  IMG_XFR_D2T  will  process  each 
file  group  in  turn  until  all  are  finished.  The  program  will  then  report  the  task  completed, 
and  exit. 

4.2.2  Create  Tape  Labels  -  CREAT_LBL__FL 
4.2.2. 1  Introduction. 

In  order  to  transfer  files  from  the  local  disk  drive  to  magnetic  tape  in  ANSI  standard 
format,  the  program  IMG_XFR_D2T  must  have  several  label  files  available  to  it,  in  addition 
to  the  actual  image  files  to  be  transferred.  For  all  files,  IMG_XFR_D2T  must  have  an 
'HDRxxx'  file  and  an  'EOFxxx'  or  'EOVxxx'  file;  these  contain  information  for  the  tape 
file's  header  and  trailer  labels.  "CREAT_LBL_FL"  is  a  small  utility  which  aids  the  user  in 
generating  these  label  files. 
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4. 2. 2. 2  Operation. 

After  CREAT_LBL_FL  is  invoked  the  program  will  ask  the  operator  for  the  name  of  a 
file  to  process.  If  the  file  is  not  found,  CREAT__ LBLJFL  will  abort  the  operation.  If  the  file 
is  found,  CREAT_LBL_FL  will  ask  the  operator  several  questions  about  the  file,  and  about 
the  manner  in  which  it  is  to  be  stored  on  tape.  First,  CREAT_LBL_FL  will  ask  for  the  file 
set  identifier;  this  is  the  set  of  files  of  which  this  file  is  to  be  a  part.  CREAT_LBL_FL  will 
then  ask  for  the  block  length  to  be  used  in  the  tape  file;  the  default  block  length  is  2048 
bytes.  If  the  file  is  direct-access,  CREAT_LBL_FL  will  preset  the  record  length;  if  the  file 
is  sequential-access,  CREAT_LBL_FL  will  query  the  operator  for  the  maximum  record 
length  (default  is  128  bytes).  Finally,  CREAT_LBL_FL  will  ask  for  the  extension  for  the 
data  files  it  is  to  write,  e.g.  if  the  user  enters  '12',  CREAT_LBb_FL  will  write  data  files 
HDR012,  E0F012. 

4.2.3  Create  Declaration  File  -  CREAT_pCLR_FL 
4.2.3. 1  Introduction 

All  government  documents  generated  in  accordance  with  MIL-STD-1840A  have 
accompanying  them  a  document  declaration  file,  which  helps  in  the  unification  and 
reproduction  of  the  document.  The  declaration  file  provides  information  about  the 
identifications,  source,  destination,  classification,  and  other  information  about  the 
document,  and  gives  a  count  of  the  files  in  the  set  of  files  that  make  up  a  complete 
document. 

CREAT_DCLR_FL  Is  designed  to  aid  In  the  creation  of  declaration  files  for  government 
documents.  Through  a  series  of  menus,  the  operator  is  allowed  to  create  new  declaration 
files,  and  view  and  update  old  files.  Although  some  error  checking  is  performed,  most  of  the 
responsibility  of  ensuring  the  validity  of  the  entries  lies  with  the  operator.  CREAT_pn,R_FL 
creates,  in  addition  to  the  declaration  file,  header  and  trailer  data  files  needed  by 
IMG_XFR_D2T  to  transfer  the  file  to  ANSI-standard  magtape. 
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4. 2. 3. 2  Operation 

Upon  initiation  CREAT_DCLR_FL  will  prompt  the  operator  for  the  Declaration  file  name 
to  process  and  whether  the  file  is  to  be  created  or  updated.  File  names  must  be  of  the  proper 
form  for  the  declaration  file,  i.e.  'Dxxx',  where  xxx  =  001. ..999.  If  the  operator  elects  to 
create  a  new  file,  CREAT_DCLR_FL  will  query  the  operator  for  non-default  entries,  and  then 
proceed  to  the  main  editing  menu.  If  the  operator  elects  to  update  an  existing  file, 
CREAT_DCLR_FL  will  attempt  to  read  in  the  current  contents  of  the  filed  specified.  If  the 
file  is  found,  it  is  loaded  and  the  program  presents  the  operator  with  the  main  editing  menu. 
If  the  file  is  not  found,  CREAT_DCLR_FL  enters  the  file  creation  sequence  and  begins  the 
generation  of  a  new  file,  as  if  the  operator  had  requested  creation  of  a  new  file. 

The  main  editing  menu  displays  the  first  75  characters  of  each  of  the  fifteen  declaration 
file  records.  The  operator  may  elect  to  edit  any  record  by  entering  the  number  of  that 
record,  or  to  exit  and  save  by  entering  'x*  at  the  prompt.  The  fifteen  records  are: 

1.  vSource  system  (srcsys:).  A  character  string  containing  the  name,  address  and 
other  information  needed  to  identify  the  system  from  which  the  information 
originated  (has  default  value). 

2.  Source  system  document  identifier  (srcdocid:).  This  is  the  character  string  used  by 
the  source  system  to  identify  a  document,  such  as  a  technical  publication  number, 
engineering  drawing  number  or  database  file  set  identifier  (has  no  default  value). 

3.  Source  system  related  document  identifier  (srcrelid:).  This  record  contains  a 
character  string  used  by  the  source  system  to  identify  another  document  to  which 
this  document  is  closely  related,  for  example  a  supplementary  document  (has 
default  of  NONE). 
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Highest  revision  and  change  level  in  the  document  (ehglvl:).  This  record 
indicates  the  revision,  level  and  date  of  the  document  If  no  changes  have  been 
made  this  record  should  contain  the  word  "ORIGINAL"  along  with  the  date.  Date 
format  is  YYYYMMDD,  where  YYYY  is  the  year,  MM  is  the  month  and  DD  is  the  day 
of  the  month  (has  no  default). 

Date  of  issue  of  the  latest  change  to  the  document  (dteisu:).  If  the  document  is 
an  original,  this  should  be  the  date  the  document  was  issued.  Date  format,  as 
before,  is  YYYYMMDD,  where  YYYY  is  the  year,  MM  is  the  month,  and  DD  is  the  day 
of  the  month  of  issue  (has  no  default). 

Destination  system  (dstsys:).  This  contains  the  name,  address  and  other 
information  needed  to  identify  the  destination  system  to  which  the  document  is 
going  (has  no  default). 

Destination  system  document  identifier  (dstdocid:).  This  record  contains  the 
character  string  used  by  the  destination  system  to  uniquely  identify  the 
document,  i.e.  this  could  be  the  service  or  agency  document,  number  (has  no 
default). 

Destination  system  related  document  identifier  (dstrelid:).  This  is  a  character 
string  used  by  the  destination  system  to  identify  another  document  to  which  this 
document  is  closely  related,  i.e.  a  document  to  which  this  document  is  a 
supplement  (has  default  of  NONE). 

Date  of  transfer  (dtetrn:).  This  is  the  date  the  document  was  transferred  by  the 
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source  system  to  . the  transmission  media.  Date  format  is  YYYYMMDD,  where  YYYY 
=  year,  MM  =  month  and  DD  =  day  of  the  month  the  file  was  transferred  (has  no 
default). 

10.  Delivery  accounting  (dlvacc:).  A  free  form  record,  this  gives  delivery  information 
specified  by  the  contract  or  other  agreement,  such  as  the  contract  number  (has 
default  of  NONE). 

11.  File  count  (filcnt:).  This  record  specifies  the  number  and  type  of  files  which 
comprise  the  document.  See  page  18  of  MIL-STD-1840A  for  the  list  of  file  codes 
(has  no  default). 

12.  Title  security  label  (ttlcls:).  This  states  the  security  /  sensitivity  level  or  other 
restriction  on  the  title  of  the  document  (has  default  of  Unclassified). 

13.  Document  security  label  (doccls:).  This  states  the  highest  security  /  sensitivity 
level  or  other  restriction  on  any  file  in  the  document  (has  default  of 
Unclassified). 

14.  Document  type  (doctyp:).  This  is  a  character  string  which  the  source  system  uses 
to  identify  a  document  or  engineering  drawing  type,  such  as  job  guide,  schematic 
diagram,  work  card  or  assembly  drawing  (has  no  default). 

15.  Document  title  (docttl:).  This  is  a  character  string  identifying  the  document,  for 
example  a  technical  publication  or  engineering  drawing  title  (has  no  default). 

The  operator  may  modify  any  or  all  of  these  from  the  change  menu.  When  creating  a  new 
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file,  CREAT_DCLR_FL  will  request  that  the  operator  enter  a  value  for  every  label  which  does 
not  have  a  default  value,  and  then  present  the  operator  with  the  change  menu.  After  loading 
a  file,  CREAT_DCLR_FL  proceeds  directly  to  the  change  menu. 

When  the  operator  enters  the  number  of  a  record  to  edit,  CREAT_DCLR_FL  first  presents 
all  of  the  label,  not  just  the  first  75  characters.  The  operator  may  at  this  time  elect  to 
return  to  the  change  menu,  or  to  edit  the  record.  If  the  operator  decides  to  edit  the  record, 
CREAT_DCLR_FL  will  step  the  operator  through  the  correct  generation  of  the  label.  For 
instance,  when  modifying  record  number  11,  file  counts,  CREAT_DCLR_FL  will  present  the 
operator  with  each  of  the  file  types  in  turn,  and  the  operator  enters  the  number  of  files  of 
each  type.  In  many  cases,  as  the  input  could  be  a  general  string,  CREAT_DCLR_FL  cannot 
provide  extensive  error  checking;  for  these  records,  CREST_DCLR_FL  accepts  a  general 
string  for  the  input,  which  the  operator  must  ensure  is  correct. 

When  finished  creating  or  editing  the  file,  the  operator  may  enter  'x'  at  the  change  menu 
prompt  to  leave.  The  operator  is  first  asked  for  the  Source  Identification  (sid).  The  operator 
is  then  asked  what  name  to  save  the  file  under;  by  simply  pressing  [ENTER]  the  filename 
'sidDOOl'  is  selected.  CREAT_DCLR_FL  then  saves  the  file  to  disk,  and  proceeds  to  header 
and  trailer  data  file  generation.  The  extenders  for  the  header  and  trailer  data  files  are 
taken  from  the  name  of  the  file  to  be  saved;  if  the  declaration  file  name  is  'sidD027,'  then 
CREAT_DCLR_FL  creates  header  and  trailer  data  files  named  'sidHDR027'  and  'sidEOF027.' 
Therefore,  the  operator  should  take  some  care  not  to  overwrite  existing  header  and  trailer 
data  file. 

4.2.4  Create  Image  Header  -  CREAT_IMG_HDR 
4.2.4. 1  Introduction 

A  raster  image  data  file  written  to  government  specifications  has  a  header  block,  which 
contains  11  records.  These  records  contain  information  which  aids  in  the  retrieval  and 
reconstruction  of  the  image.  CREAT_IMG_HDR  is  designed  to  help  automate  the  process  of 
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generating  header  records  for  raster  files,  in  accordance  with  MIL-STD-1840A  and 
MIL-R-28002. 

4. 2. 4. 2  Operation 

Upon  initiation,  CREAT_TMG_HDR  will  request  the  name  of  the  data  file  header  to  be 
created  or  updated  interactively.  The  name  of  the  data  file  header  to  be  loaded  must  be  of 
the  form  'DxxxRyyy',  where  xxx  =  a  three-digit  number  from  001  to  999  (indicating  the 
document  of  which  this  raster  file  is  a  part),  and  yyy  =  a  three-digit  number  (indicating  the 
raster  file  number  within  this  document). 

If  the  operator  specifies  the  update  option,  GREAT_IMG_HDR  will  search  for  the  specified 
file  and,  if  found,  load  it  into  memory  and  proceed  to  the  header  record  edit  menu.  If,  when 
attempting  to  load,  the  data  file  is  not  found,  CREAT__IMG_HDR  will  go  directly  to  the  header 
record  edit  menu,  with  default  values  for  the  records  in  place.  If  the  operator  specifies  file 
creation,  CREAT_IMG_HDR  proceeds  directly  to  the  header  record  edit  menu,  with  default 
values  for  the  records  in  place. 

As  each  record  is  processed  only  the  first  75  characters  of  each  record  are  displayed. 
Each  record  is  actually  128  characters  long,  but  screen  limitations  prohibit  the  display  of 
all  characters  in  the  record  edit  menu.  The  operator  may  select  which  record  to  edit  by 
entering  the  number  of  the  record  at  the  prompt,  or  may  exit  the  record  edit  menu  by 
entering  'x'  or  'X'  at  the  prompt. 

When  editing  a  record,  CREAT_IMG_HDR  will  perform  error  checking  on  inputs  when 
possible;  as  always,  the  majority  of  the  responsibility  for  error  checking  falls  to  the 
operator.  Special  care  should  be  taken  when  inputting  information  into  record  1  (srcdocid)  if 
the  file  is  a  product  data  file. 

Modifying  Records 

Any  record  may  be  selected  for  modification  from  the  record  edit  menu  by  entering  its 
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number  and  then  following  the  prompts.  Whenever  possible,  CREAT_IMG_HDR  will  provide  a 
list  of  default  values,  and  check  for  the  validity  of  input  numbers  and  character  strings. 

Record  l  -  Source  system  document  identifier  (srcdocid:). 

For  technical  publications,  this  record  shall  be  identical  to  record  1  of  the  text  file 
which  references  this  illustration.  For  product  data  files,  this  record  is  defined  in 
paragraph  5.1.5.  of  MIL-STD-1840A  and  paragraphs  5.1.9  (a)  (1)  through  (21)  of  MIL- 
STD-804  (dealing  with  aperture  card  formats). 

Record  2  -  Destination  system  document  identifier  (dstdocid:). 

This  record  contains  the  destination  organization's  document  number,  for  example  the 
technical  publication  number.  For  technical  publications,  this  record  is  identical  to 
header  record  2  of  the  text  data  file  which  references  it,  and  to  record  7  of  the 
declaration  file  (dstdocid). 

Record  3  -  Text  file  identifier  (txtfilid:). 

For  illustration  data  files  the  contents  of  this  record  are  identical  to  record  3  of  the 
text  data  file  which  references  this  illustration.  For  raster  file  page  images  of  technical 
publications,  this  record  contains  the  page  number  of  the  page  stored  in  the  raster  file. 
For  product  data,  this  record  contains  the  string  'NONE'. 

Record  4  -  Figure  identifier  (figid:). 

For  technical  publications,  the  figure  identifier  is  the  figure  number  with  which  the 
figure  is  referenced.  For  product  data,  this  record  contains  the  string  'NONE'.  (See 
paragraph  5. 1.4. 4  of  MIL-STD-1840A  for  additional  information  of  figure  identification 
in  technical  publications) 
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Record  5  -  Source  system  graphics  filename  (srcgph:). 

For  product  data  files,  this  record  contains  the  string  'NONE';  for  technical 
publications,  see  MIL-STD-1840A,  pages  22ff. 

Record  6  -  Data  file  security  label  (doccls:). 

This  is  a  character  string  stating  the  security/sensitivity  level  or  other  restrictions  on 

the  data  file. 

Record  7  -  Raster  data  type  (rtype:). 

This  is  a  single  digit  representing  the  type  of  raster  data  contained  in  the  following  file. 
A  T  indicates  a  Type  I  (untiled)  raster  file;  a  '2'  indicates  a  Type  II  (tiled)  raster  file. 
For  testing  purposes,  the  digit  '9'  may  be  appended  to  indicate  that  the  raster  file  is 
stored  in  binary  bitmap  image. 

Record  8  -  Raster  image  orientation  (rorient:). 

This  record  contains  two  right-justified,  three-character  strings  separated  by  a  comma, 
indicating  respectively  the  direction  of  the  progression  of  successive  pels  along  a  path 
relative  to  the  horizontal,  and  the  direction  of  the  progression  of  successive  lines 
relative  to  the  pel  path.  CREAT_IMG_HDR  will  allow  entry  of  values  specified  as 
permissible  by  MIL-R-28002. 

Record  9  -  Raster  Image  pel  count  (rpelcnt:). 

Two  right-justified,  six-character  strings  separated  by  a  comma  are  used  to  specify  the 
integer  count  of  pels  in  the  pel  path,  and  lines  in  the  progression  direction.  These 
values  are  dependent  upon  pel  density  per  inch,  and  upon  image  size.  MIL-R-28002 
contains  tables  for  pel  counts  for  various  size  images  (North  American  and  Metric)  at 
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200  pels  per  inch;  this  table  may  be  used  to  extrapolate  for  additional  pel  and  line 
counts.  CREAT_IMG_HDR  provides  no  error  checking  here;  therefore,  it  is  advisable  to 
double-check  when  entering  these  values. 

Record  10  -  Raster  image  density  (rdensty:). 

This  is  a  one  right-justified,  four-character  string  specifying  the  raster  image  density. 
CREAT_IMG_HDR  allows  entry  of  values  defined  as  permissible  by  MIL-R-28002  only. 

Record  11  -  Notes  (notes:). 

This  is  a  free-form  field  which  can  contain  any  special  or  additional  information 
pertaining  to  the  document  or  its  reconstruction  or  use. 

4.2.5  IMG_FILE_GEN 

4.2.5. 1  Introduction. 

IMG_FILE_GEN  is  a  utility  program  designed  to  join  header  data  and  raster  file 
information  into  one  file,  as  per  government  documents  MIL-STD-184CA  and  MIL-R-28002. 

4. 2. 5. 2  Operation. 

Upon  initiation,  IMG_FILE_GEN  prompts  the  operator  for  the  name  of  the  raster  data  file 
to  create.  In  order  to  create  the  file,  IMG_FILE_GEN  expects  two  direct-access  files  to  be 
present.  These  files  have  the  same  name  as  specified  by  the  operator  with  an  identifying 
extension.  The  file  which  contains  the  header  records  has  the  extension  ’.HDR'  and  the  file 
which  contains  the  image  data  has  the  extension  ’.DAT’;  both  of  these  files  must  be  present 
for  the  program  to  run.  For  example,  if  IMG_FILE_GEN  sidD023R001  were  entered, 
IMG_FILE_GEN  would  expect  to  find  files  sidD023R001.HDR  and  sidD023R001.DAT  for  the 
data  and  image  files,  respectively,  where  'sid'  is  the  source  identification. 

After  transferring  the  1 1  header  records  to  the  target  file,  IMG_FILE_GEN  appends  5 
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records,  each  consisting  of  128  caret  symbols  C'1'),  to  pad  out  the  first  block.  IMG_FILE_GEN 
then  transfers  all  of  the  records  from  the  image  data  file  to  the  target  file  starting  in  block 
two.  IMG_FILE_GEN  also  writes  header  and  trailer  label  files,  which  are  used  by  the 
IMG_XFR_D2T  file  to  transfer  files  from  disk  to  magtape. 

4.2.6  Image  Tape  Validation  -  IMG_TAPE_VAL 

4.2.6. 1  Introduction 

IMG_TAPE_VAL  is  a  program  designed  to  read  and  validate  an  ANSI  Standard  Raster 
Image  Tape  format.  The  image  tape  format  is  defined  by  ANSI  Standard  X3.27,  Mil-Std- 1840a 
and  Mil-R-28002.  These  standards  fully  specify  both  the  format  and  contents  of  all  data 
records  present  on  the  magnetic  tape.  The  IMG__TAPE_VAL  program  assures  that  the  raster 
image  tape  was  written  in  accordance  with  these  standards. 

4.2. 6. 2  Operation 

Upon  initiation,  IMG_TAPE_VAL  prompts  the  operator  for  a  three  character  tape 
identification  id  (user/source  id  -  e.g.  DIS)  which  is  prefaced  to  the  output  log  file 
generated  by  the  tape  validation  process.  The  raster  image  tape  is  then  read  and  verified  in 
a  sequential  manner.  All  label  records  are  formatted  and  written  to  the  system  log  file  as 
they  are  processed.  As  the  contents  of  the  declaration  file(s)  is  (are)  read,  this  information 
is  also  formatted  and  written  to  the  system  log  file.  Finally,  as  each  Image  file  is  processed, 
the  header  records  are  extracted  from  the  Image  file  and  formatted  and  written  to  the 
system  log  file.  If  the  label  format,  the  label  contents,  the  declaration  file  contents  or  the 
raster  image  file  contents  are  found  to  be  incorrect,  this  will  be  noted  in  the  system  log  file. 
In  the  event  that  an  error  is  found  in  the  format  of  the  tape,  the  error  will  be  noted  in  the 
log  file  and  the  operator  will  be  asked  whether  to  continue  or  not.  Since  an  Improperly 
formatted  tape  could  cause  the  validation  program  to  "get  out  of  step"  with  the  input  tape, 
processing  from  this  point  on  may  be  futile  and  cause  a  great  many  additional  errors. 


4  - 


16 


Upon  sucessful  completion  of  the  validation  process,  the  system  log  file  can  be  reviewed 
for  additonal  verification  of  the  tape  format  and  also  to  identify  what  raster  images  are 
present  on  the  tape.  If  the  tape  cannot  be  processed  successfully,  the  system  log  can  be 
reviewed  to  identify  that  area  of  the  tape  which  is  in  error. 

4. 2. 6. 3  IMG_TAPE_V AL  Data  Inputs 

The  operator  is  requested  to  input  a  three  character  id  to  be  used  as  a  file  preface  for 
the  system  log  file.  This  id  should  in  some  way  relate  to  the  source  of  the  image  tape  being 
validated  (e.g.  Delta  Information  Systems  -  DIS). 

4. 2. 6. 4  Program  Output 

The  IMG_TAPE_VAL  program  generates  a  formatted  log  file  which  can  be  either  displayed 
or  printed.  The  file  is  a  sequential  file,  consisting  of  ASCII  records  containing  the  contents 
of  the  labels,  declaration  file(s),  and  the  raster  image  file  header  records  from  each  image 
file  on  the  tape.  It  also  contains  error  Indication  records,  identifying  areas  of  the  tape 
where  errors  occurred. 

4.2.7  Image  Transfer  Tape  to  Disk  -  IMG_ XFR_T2D 
4.2.7. 1  Introduction. 

IMG_XFR_T2D  is  designed  to  transfer  files  from  a  Level  I,  II  or  III  ANSI-standard 
nine-track  magnetic  tape  in  labeled-file  format,  to  a  collection  of  files  on  a  local  disk.  The 
program  can  handle  "standard"  ANSI  with  block  lengths  up  to  8192  bytes.  IMG_XFR_T2D  can 
be  set  to  read  all  files  on  a  tape  to  the  disk  in  a  "batch"  dump,  or  can  be  instructed  which 
files  to  read  using  an  "ask  as  found"  system,  and  the  user  may  also  specify  a  'first  file'  to 
read  in,  in  which  case  IMG_XFR_T2D  will  search  through  the  tape  for  that  file  before 
commencing  automatic  or  queried  transfer.  The  transfer  of  a  flle(s)  from  tape  to  disk  is 
independent  of  the  file  type  and  will  transfer  the  declaration  files  as  well  as  the  raster 
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image  files. 


4. 2. 7. 2  Operation 

Upon  initiation,  IMG_XFR_T2D  prompts  the  operator  for  a  three  character  tape 
identification  Id.  This  Id  should  be  identical  to  the  one  specified  in  the  tape  validation 
process  so  that  the  system  log  for  the  image  tape  and  the  files  transferred  from  the  tape  can 
be  identified  easily.  As  was  mentioned  previously,  the  file  transfer  can  be  in  either  a 
"batch"  mode  or  in  an  "ask  as  found"  mode.  In  the  case  of  fully  automatic  transfer  or  "batch" 
mode,  operation  will  proceed  until:  the  last  file  on  the  tape  has  been  transferred  to  disk; 
the  disk  runs  out  of  room  (which  generates  an  I/O  error),  or  a  tape  read  error  is  encountered. 
If  a  file-by-file  query  is  specified,  operation  on  a  given  file  will  continue  until  the  file  is 
completely  transferred,  the  disk  runs  out  of  room,  or  a  tape  error  is  discovered.  After  a  file 
is  read  or  bypassed,  if  the  last  file  just  processed  is  not  the  last  file  on  the  tape, 
IMG_XFR_T2D  will  ask  whether  to  read  or  bypass  the  next  file.  If  the  file  just  read  or 
bypassed  was  the  last  file  on  tape,  the  program  will  exit. 

If  the  tape's  volume  header  label  is  missing,  the  operator  has  the  option  of  terminating 
operation,  or  continuing  despite  the  missing  label.  If,  in  a  given  file,  the  number  of  blocks 
counted  by  the  program  does  not  match  the  number  of  blocks  specified  in  the  trailer  label, 
IMG_XFR__T2D  will  notify  the  user  and  give  the  option  of  continuing  operation,  or  aborting 
the  read. 

Please  note  that  IMG_XFR_T2D  does  not  save  header,  trailer  and  volume  labels  other 
than  those  required  by  the  ANSI  standard.  Labels  which  are  saved  are:  VOL1  for  the  volume; 
HDR1  and  HDR2,  EOF1  and  EOF2  or  EOV1  and  EOV2  for  each  file  within  the  volume.  Other 
labels  are  not  saved  (these  labels  are  HDR3..9,  EOF3..9,  EOV3..9,  VOL2..9,  UVL1..9,  UHLx  and 
UTLx,  where  x  =  an  a-character)  and  are  ignored  by  IMG_XFR_T2D  in  the  course  of 
operations. 
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4. 2. 7. 3  IMG_XFR_T2D  Data  Inputs. 

In  fully  automatic  operation,  all  of  IMG_XFR_T2D's  input  is  supplied  by  the  tape  being 
read,  unless  the  program  requires  input  because  of  an  error  condition  (missing  volume  label, 
block  count  mismatch).  In  the  file-by-file  query  mode,  the  program  requires  the  operator  to 
input  a  'Y'  or  'y'  to  read  the  file,  a  'N'  or  'n'  input  to  skip  the  file,  or  a  ’Q'or  'q'  to  quit  the 
operation.  The  operator  may  also  elect  to  enter  a  filename,  which  IMG_XFR_T2D  will  search 
for  before  performing  any  transfers.  When  the  file  is  located,  IMG_XFR_T2D  will  begin 
automatic  or  queried  transfers,  starting  with  the  named  file  (note:  if  the  operator  selected 
queried  transfer,  IMG_XFR_T2D  will  first  transfer  the  named  file,  and  then  do  a  file-by-file 
query  on  all  subsequent  files). 

4.2. 7. 4  Program  Output 

All  data  read  from  the  tape  files  (with  the  exception  of  extraneous  labels)  are  stored  in 
disk  files.  Status  reports  are  sent  to  the  screen  when  appropriate,  as  are  error  messages  and 
queries. 

4. 2. 7. 4.1  Disk  File  Output  -  Storage  and  Naming  Conventions 

IMG_XFR_T2D  creates  two  classes  of  disk  files  as  its  output.  The  first  class  of  files 
stores  information  about  the  way  the  tape  file  was  stored,  such  as  labels,  number  of  records, 
etc.  The  second  class  of  files  stores  the  actual  records  from  the  tape  file,  and  are  known  as 
"data-of-interest,"  or  DAT,  files. 

Each  DAT  file  from  the  tape  has  associated  with  it  several  information  files. 
IMG_XFR__T2D  information  file  names  consist  of  a  three  character  Source  Identification  (sid), 
a  two  or  three  character  code  followed  by  a  three  digit  number  identifying  the  ordinal  place 
the  file  had  on  the  tape.  The  information  file  names  and  the  information  they  contain  are: 
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sidHDRnnn  -  contains  information  from  the  HDR1  and  HDR2  label  of  the  file. 
sidEOFnnn  -  contains  information  from  the  EOF1  and  EOF2  labels  of  the  file.* 
sidEOVnnn  -  contains  information  from  the  EOV1  and  EOV2  labels  the  file.* 

*  a  given  DAT  file  will  have  associated  with  it  either  an  EOF  or  an  EOV  information  file, 
but  not  both. 

All  of  the  information  files  IMG_XFR_T2D  creates  are  sequential  access  files.  A  given 
DAT  file  will  be  sequential  access  if  the  original  tape  file  consisted  of  variable  length 
records,  or  direct  access  if  the  original  tape  file  consisted  of  fixed  length  records.  This  is 
done  to  preserve,  as  closely  as  possible,  th  iginal  structure  of  the  tape  file  on  disk. 

The  names  of  the  DAT  files  are  taken  from  the  file  identifier  in  Header  Label  1. 

4.2. 7.4. 2  Disk  File  Output  -  Contents  and  Organization 

-  Header  and  Trailer  Information  Files  (HDR,  EOF,  EOV  Files) 

Header  and  trailer  information  files  (HDR,  EOF  and  EOV  files)  are  recorded  using  the 
same  structure  by  IMG__XFR_T2D;  therefore,  a  common  treatment  of  their  organization  shall 
be  given. 

Each  header  or  trailer  information  file  recorded  by  IMG_XFR_T2D  consists  of  exactly 
two  sequential  access  records,  each  record  80  characters  long.  The  first  record  contains, 
verbatim,  the  Information  stored  in  the  file's  HDR1,  EOF1  or  EOV1  label;  the  second  record 
contains,  verbatim,  the  information  stored  in  the  file's  HDR2,  EOF2  or  EOV2  label. 

-  "Information-of-Tnterest"  Files  ("DAT"  Files) 

IMG_XFR_T2D  was  designed  to  transfer  files  from  tape  to  disk  in  a  manner  which 
modifies  the  original  structure  of  the  record  as  little  as  possible,  while  allowing  it  to  remain 
usable  to  already  existing  image  compression  and  decompression  programs.  Therefore,  the 
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file  will  be  written  in  one  of  two  formats,  depending  upon  the  tape  file's  record  format. 

If  the  original  tape  file  consisted  of  fixed  length  records,  IMG_XFR_T2D  will  place  the 
records  in  a  direct  access  disk  file.  If  the  original  tape  file  consisted  of  variable  length 
records,  IMG_XFR_T2D  will  place  the  records  in  a  sequential  access  disk  file.  The 
sequential  access  disk  file  will  not  contain  the  RCW  (record  control  word)  from  the  tape 
records,  but  only  the  actual  records. 

4.2.8  Image  File  Split  -  IMG_FILE_SPLT 

4.2.8. 1  Introduction 

IMG_FILE_SPLT  is  a  utility  program  designed  to  split  a  raster  image  file,  as  specified  in 
MIL-STD-1840A  and  MIL-R-28002,  into  a  header  record  file,  and  an  image  data  file.  The 
header  record  file  contains  the  1 1  header  records  which  contain  information  about  the  raster 
file;  the  image  data  file  contains  all  of  the  encoded  picture  information. 

4.2. 8. 2  Operation 

The  IMG_FILE_SPLT  program  prompts  for  the  name  of  the  raster  image  file  to  be 
processed.  If  the  file  cannot  be  found  the  operation  will  be  aborted.  After  verifying  the 
existence  of  a  raster  data  file,  IMG_FILE_SPLT  will  split  the  file  Into  two  separate  files, 
which  are  given  the  original  file's  name  with  separate  extenders.  The  header  records  are 
placed  in  a  direct-access  file  with  the  extension  '.HDR,'  and  the  image  binary  data  is  placed 
in  a  direct-access  file  with  the  extension  ’.DAT.’  Therefore,  if  the  original  file  was  named 
'sidD001R027,'  IMG__FILE_SPLT  would  create  two  files  named  'sidD001R027.HDR*  (for  the 
header  records)  and  'sidD001R027.DAT'  (for  the  raster  image  binary  data). 

4.2.9  Raster  Image  Verification  -  I1IG_FILE__CIIP 
4.2.9. 1  Introduction 

With  the  completion  of  the  image  file  spilt,  the  resulting  raster  binary  data  files  are 
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ready  to  be  processed  by  the  Conformance  System  comparator  software  for  Recommmendation 
T.6  verification.  At  this  time  the  information  for  each  image  file  consists  of  a  header  record 
file  and  a  raster  binary  data  file.  The  header  record  file  contains  the  image  identification 
and  characteristics.  The  raster  binary  data  file  is  the  compressed  or  uncompressed  data  for 
that  image.  The  comparison  software  using  the  header  information,  selects  the  corresponding 
Conformance  System  "good"  image  and  compares  it  against  the  image  to  be  verified.  If  the 
image  compares  successfully,  the  file  is  marked  as  verified.  If  the  image  compare  fails,  an 
image  error  message  is  displayed  and  logged  along  with  the  information  required  to  identify 
the  error  type  and  where  in  the  image  it  occurred. 

4.2. 9. 2.  Operation 

The  IMG_FILE_CMP  program  prompts  the  operator  for  the  3  character  Id  assigned 
previously  to  the  image  files  as  they  were  transferred  from  tape.  The  operator  is  then 
prompted  for  the  names  of  the  image  files  to  be  verified.  Once  the  image  file  selection  is 
complete,  the  comparison  software  will  open  the  disk  files  (header  &  data)  for  the  image  file 
to  be  verified.  Using  the  file  identification  information  in  the  header  file  the  corresponding 
"good"  image  file  is  opened.  The  header  file  information  describing  the  image  to  be  verified 
is  compared  against  the  Conformance  System  image  information.  Any  descrepancies  will  be 
displayed/logged,  and  the  operator  will  be  asked  whether  to  continue  or  not.  If  the 
information  agrees,  the  raster  binary  data  comparison  will  be  done.  If  a  miscompare  is 
detected  and  the  file  type  being  compared  is  an  uncompressed  (bit  mapped)  image,  the  line 
number  and  bit  position  within  the  image  will  be  displayed  and  logged.  The  operator  will  be 
asked  whether  to  continue  or  not.  If  the  operator  decides  to  continue,  the  comparison  will 
restart  at  the  next  bit  position.  If  a  miscompare  is  detected  and  the  file  type  being  compared 
is  a  compressed  (encoded)  image,  the  bit  position  within  the  image  will  be  displayed  and 
logged.  The  comparison  will  terminate  at  this  point  since  further  comparison  is  meaningless. 
If  the  comparison  of  the  User's  image  with  the  Conformance  System's  image  is  successful,  the 
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Image  name  will  be  logged  with  a  completed  status. 

4.2. 9. 3  IMG_FILE_CMP  Data  Inputs 

The  operator  is  required  to  input  the  3  character  User  ID  in  order  to  identify  the  User's 
Image  file  set  to  be  processed.  In  addition,  the  operator  will  be  requested  to  input  the 
name(s)  of  the  image  file(s)  to  be  processed/compared. 

4.2. 9. 4  Program  Output 

The  IMG_FILE_CMP  program  generates  a  formatted  system  log  which  consists  of  the 
listing  of  each  file  name  processed  and  also  the  results  of  the  comparison.  This  log  will  also 
list  any  errors  that  occurred  during  the  processing  of  an  image  file. 
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5 . 0  APPENDICES 


5.1  Testing  Procedure  for  Systems  Undergoing  Conformance  Testing 

5.1.1  Introduction 

Raster  image  processing  performed  in  accordance  with  the  government 
standards  and  specifications  MIL-STD-1840A  and  MIL-R-28002  may  be 
thought  of  as  occurring  in  two  distinct  phases.  The  first  phase  of 
operation  involves  the  storage  and  retrieval  of  raster  image  files, 
along  with  other  related  files,  from  a  mass  storage  medium  of  some 
sort.  The  second  phase  of  operation  involves  the  compression, 
decompression  or  other  manipulation  of  the  stored  images.  The  testing 
procedure  outlined  in  this  document  is  designed  to  test  a  system’s 
ability  to  retrieve,  process  and  store  images  in  compliance  with  MIL- 
STD-1840A  and  MIL-R-28002. 

The  system  being  tested  must  be  able  to  retrieve  the  images  from  9- 
track  magnetic  tape,  process  the  images  in  the  manner  indicated  by  the 
testing  procedure,  and  store  the  images  back  to  tape  in  the  format  set 
forth  in  MIL-STD-1840A  and  MIL-R-28002. 

Because  part  of  the  test  package  consists  of  binary  bitmapped 
images,  it  is  assumed  that  the  system  being  tested  has  the  ability  to 
compress  and  generate  binary  bitmap  images  in  the  course  of  operation. 

5.1.2  Features  to  be  tested 

Not  all  aspects  of  MIL-STD-1840A  concern  the  processing  of  raster 
image  files.  This  test  procedure  is  designed  to  test  only  those 
features  which  have  bearing  upon  image  processing  as  defined  in  MIL- 
STD-1840A  and  MIL-R-28002;  other  features  described  in  these  documents 
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are  outside  the  provence  of  raster  image  processing  and  will  not  be 
tested. 

The  following  features  set  forth  in  MIL-STD-1840A  shall  be  tested: 

-  magnetic  tape  format  and  naming  conventions,  as  described 
in  paragraphs  5.1.1,  5.1.3,  and  5.2.1. 

-  document  declaration  file 

o  all  15  records  must  be  present 
o  all  15  records  must  contain  valid  and  correct 
information1 

-  raster  data  file  header  records 

o  all  11  records  must  be  present 
o  all  11  records  must  contain  valid  and  correct 
information2 

The  features  specified  in  MIL-R-28002  shall  be  tested  using  two  sets 
of  raster  images.  One  set  shall  consist  of  binary  bitmap  images?  the 
other  set  shall  be  encoded  in  Group  4  code.  Each  set  shall  constitute 
one  document.  Both  documents  may  be  stored  on  a  single  magnetic  tape, 
or  each  document  may  be  stored  on  a  separate  tape.  Each  set  of  images 
is  designed  to  test  the  system's  processing  ability  for  a  variety  of 
different  image  sizes  and  coding  situations.  In  general,  the  images 
will  run  from  the  simplest  to  the  most  complex.  Images  in  the  two 
documents  will  be  similar  but  not  identical. 


1  Specific  values  permissible  for  the  document  declaration 
file  record  entries  may  be  found  in  Appendix  A. 


2Specific  values  permissible  for  raster  data  file  header 
record  entries  may  be  found  in  Appendix  B. 
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The  test  images  will  be  designed  to  verify  the  system's  ability  to 
handle  the  following  situations: 


page  sizes  from  A  through  K  (North  American) ,  (See  TABLE  I)  and  A4 
through  AO  (Metric) 


o  testing  will  not  include 
non-standard  image  sizes 

o  every  page  size  will  be 
present  in  the  test  set, 
although  every  test  size 
may  not  appear  in  each 
document 

coding  of  pass  mode,  vertical 
modes,  and  horizontal  modes 

o  all  horizontal  codes  shall 
be  tested 

-  lines  and  images  with  a 

compression  factor  of  less 
than  one 

compressed  images  with  incorrect 
encoding  to  check  error  recovery 


Table  I  - 

NORTH  AMERICAN  DRAWING  SIZES 


DRAWING 

SIZE 

WxL 

(max) 

inches 

PELS 

PER 

LINE 

LINES 

PER 

DRAWING 

A 

8.5x11 

1728 

2200 

B 

11x17 

2240 

3400 

C 

17x22 

3456 

4400 

D 

22x34 

4416 

6800 

E 

34x44 

6848 

8800 

F 

28x40 

5632 

8000 

G 

11x90 

2240 

18000 

H 

28x143 

5632 

26000 

J 

34x176 

6848 

35200 

K 

40x143 

8064 

28600 

o  error  report  should  include 
location  at  which  error 
was  detected 

o  images  incorrectly  encoded 

need  not  be  returned  as  part 
of  the  processed  test  set 


The  images  themselves  may  consist  of  scanned  and/or  computer  generated 
images. 


5.1.3  Features  not  to  be  tested 

The  following  features  of  MIL-STD-1840A  and  MIL-R-28002  shall  not  be 
tested: 

-  ability  to  process  any  document  file  type  other  than 
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raster  images 

-  ability  to  process  Type  II  documents  (tiled  format) 

-  ability  to  convert  between  wrap  and  non-wrap  compression 

5.1.4.  Testing  environment  limitations  and  modifications 

For  the  purposes  of  this  test,  the  following  modifications  to  the 
standards  and  specifications  set  forth  in  MIL-STD-1840A  and  MIL-R-28002 
shall  apply: 

-  magnetic  tape  density  shall  be  limited  to  1600  cpi 

-  image  pel  density  shall  be  limited  to  200  pels  per  inch 

-  image  orientation  shall  be  limited  000,270  (portrait)  or 

090,270  (landscape)  orientation 

-  record  7  in  the  raster  data  file  headers  must 
contain  a  '9'  instead  of  a  ' 1'  or  '2'  if  the  image  is 
a  binary  bitmap  image;  this  is  done  in  order  to  allow 
the  identification  of  binary  bitmap  images.  Note  that 
this  is  NOT  in  accordance  with  MIL-STD-1840A  and 
MIL-R-28002  and  is  to  be  used  only  for  the  purposes 
and  duration  of  this  test. 

5.1.5  General  testing  procedure 

The  organization  responsible  for  the  system  being  tested  performs 
the  first  part  of  the  test  procedure  by  submitting  a  request  to  the 
Conformance  Testing  Laboratory  ("test  facility"),  which  will  assemble 
and  return  a  test  package.  This  test  package  will  consist  of  two  sets 
of  raster  image  files,  stored  in  accordance  with  MIL-STD-1840A  and  MIL- 
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R-28002  and  organized  into  two  documents.  The  first  set  (or  document) 
will  consist  of  uncompressed,  binary  bitmap  images  of  various  size  and 
content.  The  second  set  will  consist  of  images  compressed  in 
accordance  with  CCITT  Group  4  encoding  of  various  size  and  similar 
(though  not  identical)  content  to  the  first  set. 

The  system  being  tested  will  then  compress  the  uncompressed  images 
(from  set  1)  using  the  Group  4  algorithm,  and  decompress  the  compressed 
images  (from  set  2) .  Both  groups  of  images  will  then  be  written  back 
to  magnetic  tape  in  MIL-STD-1840A  and  MIL-R-28002  format.  These  image 
sets  will  then  be  returned  to  the  test  facility,  along  with  all 
completed  documentation  forms  and  any  additional  information  necessary. 

The  test  facility  will  then  process  the  two  image  sets.  The 
compressed  images  from  set  1  will  be  decompressed  and  compared  to  the 
original  binary  bitmap  images.  The  decompressed  images  from  set  2  will 
be  recompressed  and  compared  to  the  original  compressed  images.  This 
procedure  verifies  the  image  processing,  as  well  as  the  information 
contained  in  the  raster  data  file  header  records  regarding  image 
orientation  and  dimension,  and  pel  density.  The  results  of  this 
comparison  will  be  documented  and  included  in  a  conformance  test 
report.  The  test  facility  will  then  notify  the  system  undergoing 
testing  and  the  CALS  DSREDS/EDCARS  Management  Group  of  the  test 
results,  along  with  a  recommendation  for  acceptance  or  rejection  of  the 
system  being  tested.  This  recommendation  signifies  conformance  under 
the  specified  system  only,  does  not  indicate  whether  the  system  being 
tested  will  conform  or  not  under  a  different  configuration.  The  CALS 
DSREDS/EDCARS  Management  Group  has  final  authority  over  acceptance  and 
rejection.  If  accepted,  a  Letter  of  Certification  will  be  issued  to 
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the  system  being  tested,  which  is  valid  only  under  the  configuration 
under  which  the  test  was  performed. 
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Appendix  A:  Permissible  Values  for  Document  Declaration  File 
Records 

All  15  records  in  the  document  declaration  file  must  be  present,  and 
contain  valid  and  correct  information.  A  list  of  the  records,  and  the 
information  which  they  must  contain,  followed  by  a  sample  document 
declaration  file. 

Record  1  -  srcsys:.  This  record  must  contain  the  name  and  address  of 
the  organization  responsible  for  the  system  being  tested. 

Record  2  -  srcdocid:.  This  record  must  contain  a  test  identification 
number,  supplied  by  the  test  facility. 

Record  3  -  srcrelid:  NONE 

Record  4  -  chglvl:  ORIGINAL,  YYYYMMDD 

Record  5  -  dteisu:  YYYYMMDD  (this  date  should  be  the  same  as  the  date 
in  record  4} 

Record  6  -  dstsys:.  This  record  should  contain  the  name  and  address  of 
the  test  facility. 

Record  7  -  dstdocid:.  This  should  be  the  test  identification  number, 
the  same  as  in  record  2. 
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Record  8  -  dstrelid:  NONE 

Record  9  -  dtetrn:  YYYYMMDD  {this  is  the  date  this  document  was 
transferred  to  magnetic • tape) 

Record  10  -  dlvacc:  NONE 

Record  11  -  filcnt:  RNN  (where  NN  =  number  of  raster  image  files  in 
this  document) 

Record  12  -  ttlcls:  Unclassified 

Record  13  -  doccls:  Unclassified 

Record  14  -  doctyp:  Test  Images 

Record  15  -  docttl.  Conformance  Test  Package 
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Sample  Document  Declaration  File 

srcsys:  Tested  Systems,  Inc.,  123  Tester  Drive,  Philadelphia,  PA  19191 

srcdocid:  124C41 

srcrelid:  NONE 

chglvl :  ORIGINAL,  19890719 

dteisu :  19890719 

dstsys:  Delta  Information  Systems,  Horsham  .Business  Center,  300  Welsh 

Road,  Horsham,  PA  19044 

dstdocid:  124C41 

dstrelid:  NONE 

dtetrn:  19890721 

dlvacc :  NONE 

filcnt:  R13 

ttlcls:  Unclassified 

doccls:  Unclassified 

doctyp:  Test  Images 

docttl:  Conformance  Test  Package 
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Appendix  B:  Permissible  Values  for  Raster  Data  File  Header 
Records 

All  11  records  of  the  raster  data  file  header  records  must  be 
present,  and  contain  valid  and  correct  information.  A  list  of  the 
records  and  the  information  which  they  must  contain  follows. 

Record  1  -  srcdocid: .  Refer  to  Paragraph  5.1.5  of  MIL-STD-1840A 

Record  2  -  dstdocid:  NONE 

Record  3  -  txtfilid:  NONE 

Record  4  -  figid:  NONE 

Record  5  -  srcgph:  NONE 

Record  6  -  doccls:  NONE 

Record  7  -  rtype:.  Contains  a  *1'  for  compressed  images,  or  a  '9'  for 
binary  bitmap  images 

Record  8  -  rorient:.  Contains  '000,270'  for  portrait,  or  '090,270'  for 
landscape 

Record  9  -  rpelcnt:  MMMMMM , NNNNNN  ( MMMMMM  =  #  pels  /  line,  NNNNNN  = 
lines  per  page) 
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Record  10  -  rdensty:  200 


Record  11  -  notes:.  This  record  may  contain  a  comment,  or  'NONE'. 
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5.2  Testing  Procedure  -  Instructions  for  Systems  Undergoing 
Testing 

Testing 

Procedure 


Instructions  for 
Systems  Undergoing  Testing 

Read  These  Instructions  Before 

Proceeding  Further 
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5.2.1  Inventory 

The  following  should  be  found  in  the  Conformance  Testing  Package: 

1  copy  of  Testing  Procedure  -  Instructions  for  Systems 
Undergoing  Testing  (this  document) 

1  Raster  Conformance  Test  Specification  sheet 
1  Raster  Test  Release  Authorization  sheet 
1  Raster  Conformance  Test  Log  sheet 
1  Raster  Test  Incident  Report  sheet 
1  Raster  Conformance  Processed  Files  sheet 
1  Raster  Test  Results  File  sheet 
1  sample  packet  of  completed  forms 

_  reel(s)  of  9-track  magnetic  tape  9  1600  cpi  density 

If  any  item  on  this  list  is  missing,  please  contact  the  Conformance 
Testing  Laboratory  ("test  facility")  immediately. 

5.2.2  Introduction 

This  document  contains  the  instructions  and  information  you  will 
need  to  process  the  test  images  and  complete  the  associated 
documentation  forms  and  reports.  Make  photocopies  of  all  of  the 
enclosed  forms  (especially  the  Raster  Conformance  Test  Log  and  Raster 
Test  Incident  Report  sheets).  Please  note  that,  as  of  this  point,  any 
actions  taken  with  the  magnetic  tape  reels  must  be  recorded  as  part  of 
the  testing  procedure. 


5-13 


Each  of  the  forms  included  with  this  package  has  a  particular 
purpose  and  use  in  the  test  reports.  The  Raster  Conformance  Test 
Specification  sheet  is  used  to  record  a  list  of  all  files  read  from  the 
tape(s).  If  the  file  is  a  raster  file,  the  entry  will  also  list  the 
file  type  {compressed  or  uncompressed) ,  image  dimensions  and 
orientation.  You  may  also  include  a  short  description  of  the  file’s 
contents,  although  this  is  not  required. 

The  Raster  Test  Release  Authorization  merely  authorizes  the  test 
facility  to  release  the  results  of  the  test  to  the  National  Institute 
of  Standards  and  Technology.  This  should  be  completed  by  the 
supervisor  or  head  of  the  organization  responsible  for  the  system  being 
tested. 

The  Raster  Conformance  Test  Log  is  used  to  describe  the  events  that 
take  place  during  testing.  There  are  spaces  for  the  date  and  time  the 
event  in  question  took  place,  a  short  description  of  what  was  done  and 
what  took  place,  and  a  space  for  incident  references.  If  an  incident 
requiring  further  description  takes  place,  make  a  notation  in  the 
'Incident  Report  #'  column  and  fill  out  an  Incident  Report;  major 
events,  such  as  errors  in  processing  or  the  end  of  a  test  run,  are 
typical  Incident  Report  topics.  A  separate  log  should  be  kept  for  each 
major  phase  of  the  test,  for  example,  there  should  be  a  separate  log 
for  the  compression  of  the  uncompressed  images,  and  for  the 
decompression  of  Group  4  encoded  images. 
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The  Raster  Test  Results  File  sheet  should  be  filled  out  by  the  test 
system’s  team  leader,  the  supervisor  or  client  representative  for  the 
company  undergoing  testing,  and  an  observer  of  the  proceedings 
involving  the  test.  This  is  a  certification  that  the  documentation 
returned  with  the  processed  tapes  is  complete  and  accurate. 

Every  file  processed  and  transferred  back  to  magnetic  tape  should  be 
entered  on  the  Raster  Conformance  Processed  Files  sheet.  Along  with 
the  image  names,  include  the  file's  storage  type  (either  binary  bitmap 
or  Group  4  code) ,  tape  the  file  is  on  (if  there  is  more  than  one  tape 
volume),  image  orientation  and  dimensions,  and  any  comments  you  may 
have  about  the  image. 

There  is  also  a  sample  packet  of  completed  forms  with  this  package. 

5.2.3  Recommended  Testing  Procedure 

The  Raster  Conformance  Test  Log  ("log")  must  be  kept  up  to  date  and 
accurate  during  all  phases  of  testing,  and  a  separate  log  kept  for  each 
of  the  major  phases  mentioned  below.  Each  entry  in  the  log  should 
contain  a  brief  description  of  the  event,  and  the  name  of  the  software 
in  use  at  the  time  the  event  took  place.  References  to  incident 
reports  should  be  numbered  consecutively.  Each  log  entry  does  not 
require  an  incident  reports;  incident  reports  are  generally  reserved 
for  events  which  have  a  major  impact  on  the  testing  procedure  or 
sequence,  such  as  an  error  during  image  compression,  the  completion  of 
a  test  run  (successfully  or  not),  a  major  catastrophe  in  the  system's 
memory,  or  other  event  of  similar  magnitude. 
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The  exact  testing  procedure  will  vary  from  system  to  system; 
however,  the  general  procedure  outlined  below  is  applicable  to  all 
systems . 

5. 2. 3.1  Initial  Transfer  of  File  Set  #1  (Uncompressed  Bitmapped  Images) 
The  recommended  first  stage  of  testing  is  the  transfer  of  the 

uncompressed  binary  bitmap  files  from  MIL-STD-1840A  tape  format  to  a 
form  which  the  system's  Group  4  coder  can  process.  As  the  files  are 
transferred  from  tape,  record  the  file  name,  image  dimensions  and 
orientation  on  the  Test  Specification  Sheet.  (If  the  system  has 
appropriate  facilities,  the  tester  may  also  provide  a  brief  description 
of  the  image  on  the  test  specification  sheet.)  Note  the  transfer  in 
the  log,  along  with  any  error  events  or  incidents  of  note  in  incident 
reports.  This  step  should  be  repeated  until  all  files  in  File  Set  #1 
are  successfully  transferred,  as  any  information  garbling  at  this  stage 
will  affect  all  other  operations  on  File  Set  #1. 

5. 2. 3. 2  Compression  of  File  Set  #1 

Compression  of  File  Set  #1  is  the  next  step.  The  compression  of 
each  individual  file  should  be  recorded  in  the  log,  and  incidents 
reported  as  appropriate.  Note  that  some  files  may  have  negative 
compression. 


5 .2. 3. 3  Initial  Transfer  of  File  Set  #2 

The  transfer  procedure  for  the  compressed  image  test  set  is 
approximately  the  same  as  that  for  File  Set  #1.  The  same  information 
and  parameters  are  recorded  to  the  Test  Specification  Sheet  and  log. 

5. 2. 3. 4  Decompression  of  File  Set  #2 

Decompression  of  File  Set  #2  should  follow  basically  the  same  format 
as  that  taken  with  the  compression  of  File  Set  #1.  Make  a  notation  of 
the  decompression  of  each  individual  file  in  the  log,  along  with  any 
errors  or  especially  noteworthy  incidents  in  incident  reports.  At  this 
point,  the  tester  may  optionally  write  a  short  description  of  the  image 
on  the  Test  Specification  sheet.  Please  note  that  at  least  one  image 
in  File  Set  #2  may  be  improperly  coded.  It  is  not  necessary  to 
decompress  an  improperly  coded  image;  it  should  not  be  included  with 
the  other  files  of  File  Set  #2  when  transferring  the  decompressed 
images  back  to  tape.  However,  the  incident  report  should  document  the 

coding  error  as  fully  as  possible,  e.g.  line  where  the  error  was 

detected,  nature  of  the  coding  error,  etc. 

5. 2. 3. 5  Final  Transfer  of  File  Sets  #1  and  #2 

At  this  point,  all  files  in  File  Set  #1  are  encoded  using  Group  4 
compression,  and  all  files  in  File  Set  #2  are  in  binary  bitmap  format 

(barring  the  file(s)  with  improper  coding).  These  files  will  then  be 

transferred  back  to  magnetic  tape  as  two  separate  documents,  File  Set 
#1  comprising  one  document  and  File  Set  #2  comprising  the  other.  Once 
again,  enter  these  events  into  the  log,  and  record  any  errors  or  other 
significant  events  in  incident  reports.  Repeat  this  step  until  it  is 
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performed  without  error.  Note  also  that  if  your  original  test  set 
contained  one  magnetic  tape,  both  documents  should  be  returned  on  a 
single  tape;  if  the  test  set  contained  two  tapes,  then  the  documents 
should  be  stored  on  separate  magnetic  tapes. 

As  each  document  is  stored  to  tape,  enter  it  on  the  Raster 
Conformance  Processed  Files  sheet. 

5. 2. 3. 6  Completion  of  Report  Forms 

The  Raster  Test  Release  Authorization  sheet  must  be  completed  by  an 
individual  with  the  authority  to  authorize  the  release  the  results  of 
the  Conformance  Test  to  the  National  Institute  of  Standards  and 
Technology. 

The  conformance  test  team  leader,  an  authorized  client 
representative,  and  a  designated  observer  who  was  present  during  the 
entire  test  must  complete  the  Raster  Test  Results  File  form.  This  form 
states  that  the  returned  documentation  is  the  complete  and  accurate 
record  of  the  testing  and  processing  performed. 


5.4  Test  Package  Return 

Mark  the  processed  tapes  clearly,  and  indicate  their  contents. 
Return  to  the  test  facility  a  package  containing  the  reel(s)  of 
magnetic  tape  containing  the  processed  images,  the  completed  test  log, 
all  associated  incident  reports,  the  completed  Results  File  sheet,  and 
the  completed  Release  Authorization  sheets.  The  absence  or 
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incompleteness  of  any  portion  of  the  test  package  will  result  in  a 
negative  evaluation  by  the  test  facility. 
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Raster  Conformance 


Test  Specification 

Client  Request  Number:  _ 

Client  Name:  _ 

Test  Cases 

(List  both  compressed  and  uncompressed  images) 

Filename_ Orientation_ Dimensions_ Comments /Notes 


Raster  Test 
Release  Authorization 

_  hereby  authorizes  the 

(Company  Undergoing  Test) 

Conformance  Testing  Laboratory  _ 

to  release  the  Conformance  Test  Report  to  the  National  Institute 
of  Standards  and  Technology  for  general  distribution.  The  test 
is  identified  as:  _ . 

(Client  Request  Number) 

Authorized  Signature:  _ 

Name :  _ 

Title:  _ 

Date:  _ 
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Raster  Conformance 
Test  Log 

Client  Request  Number: 

Test  Description: 

Date  /  Time  Activities  and  Event  Entries _ Incident  Report  # 


Raster  Test 
Results  File 


Client  Request  Number: 
Software  Identification: 


The  undersigned  certify  that  the  material  and  records  contained  in  this 
file  are  all  those  and  only  those  associated  with  the  above  identified 
Group  4  Compression  /  Decompression  test. 


(Team  Leader ) 


(Client  Representative) 


(Observer) 


(Af f 1 1 latlon) 


(Affiliation) 


(Affiliation) 


o  - 
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Raster  Test 
Incident  Report 


Client  Request  Number: 
Incident  Report  Number: 
Description  of  Incident: 


Impact  of  Incident  Upon  Test: 


f 


5-24 


Raster  Conformance 
Processed  Files 


Client  Request  Number:  _ 


Client  Name: 


Test  Cases 


Filename  Storaqe  Tape  #  Orientation  Dimensions  Comments 


